과제 체크포인트

배포 링크

기본과제

목표 : 전역상태관리를 이용한 적절한 분리와 계층에 대한 이해를 통한 FSD 폴더 구조 적용하기

• 전역상태관리를 사용해서 상태를 분리하고 관리하는 방법에 대한 이해
• Context API, Jotai, Zustand 등 상태관리 라이브러리 사용하기
• FSD(Feature-Sliced Design)에 대한 이해
• FSD를 통한 관심사의 분리에 대한 이해
• 단일책임과 역할이란 무엇인가?
• 관심사를 하나만 가지고 있는가?
• 어디에 무엇을 넣어야 하는가?

체크포인트

• 전역상태관리를 사용해서 상태를 분리하고 관리했나요?
• Props Drilling을 최소화했나요?
• shared 공통 컴포넌트를 분리했나요?
• shared 공통 로직을 분리했나요?
• entities를 중심으로 type을 정의하고 model을 분리했나요?
• entities를 중심으로 ui를 분리했나요?
• entities를 중심으로 api를 분리했나요?
• feature를 중심으로 사용자행동(이벤트 처리)를 분리했나요?
• feature를 중심으로 ui를 분리했나요?
• feature를 중심으로 api를 분리했나요?
• widget을 중심으로 데이터를 재사용가능한 형태로 분리했나요?

심화과제

목표: 서버상태관리 도구인 TanstackQuery를 이용하여 비동기코드를 선언적인 함수형 프로그래밍으로 작성하기

• TanstackQuery의 사용법에 대한 이해
• TanstackQuery를 이용한 비동기 코드 작성에 대한 이해
• 비동기 코드를 선언적인 함수형 프로그래밍으로 작성하는 방법에 대한 이해

체크포인트

• 모든 API 호출이 TanStack Query의 useQuery와 useMutation으로 대체되었는가?
• 쿼리 키가 적절히 설정되었는가?
• fetch와 useState가 아닌 선언적인 함수형 프로그래밍이 적절히 적용되었는가?
• 캐싱과 리프레시 전략이 올바르게 구현되었는가?
• 낙관적인 업데이트가 적용되었는가?
• 에러 핸들링이 적절히 구현되었는가?
• 서버 상태와 클라이언트 상태가 명확히 분리되었는가?
• 코드가 간결하고 유지보수가 용이한 구조로 작성되었는가?
• TanStack Query의 Devtools가 정상적으로 작동하는가?

최종과제

• 폴더구조와 나의 멘탈모데일이 일치하나요?
• 다른 사람이 봐도 이해하기 쉬운 구조인가요?

과제 셀프회고

이번 과제를 통해 이전에 비해 새롭게 알게 된 점이 있다면 적어주세요.

이번 과제에선 FSD 아키텍쳐를 적용해보며 도메인 별 로직을 어떻게 분리해야할지, 같은 도메인 내에서도 UI 로직과 비즈니스 로직 등은 어떻게 분리해야할지 고민하면서,

결합도는 낮지만 응집도는 높은 코드를 작성하는 방법, 관심사를 분리하는 방법 등에 대해 많은 것을 배울 수 있었다.

본인이 과제를 하면서 가장 애쓰려고 노력했던 부분은 무엇인가요?

1. 현재 회사에서도 fsd를 적용하자고 하고 있어서 이번 과제에서는 최대한 fsd 구조를 그대로 따라 코드를 분리해보려는 개인적인 목표를 삼았다. 물론 과제에 있는 서비스나 규모가 그에 비해 작아서 실제로는 fsd를 부분 차용해서 하는게 좋겠지만 fsd에서 소개하는 각 레이어, 슬라이스, 세그먼트 등을 꼼꼼히 공부하고 각각 활용해보고 싶었다.

2. 이번 과제에서 dummyjson을 쓰기 때문에 update나 delete 요청 시 실제로 데이터가 바뀌지는 않아서, invalidateQueries를 통해 캐시를 무효화하고 refetching을 시도하는 경우 원래 데이터로 다시 바뀌기 때문에 실제 화면 상에서는 update나 delete가 동작하지 않는 것처럼 보이는데, 억지로 되는 것처럼 보이게 짜는 것보다는 실제 코드처럼 작성하고 싶어서 그대로 두고 대신 이 과정을 UI 상으로 나타내기 위해 토스트 알럿을 추가했다.

3. 실무에서 queryKey를 따로 관리하고 있지 않은데, 이번 과제를 하면서 tkdodo 블로그 를 참고해서 queryOption을 활용해 queryKey를 관리했다.

아직은 막연하다거나 더 고민이 필요한 부분을 적어주세요.

여러 도메인이 존재하는 환경에서, 2~3개의 도메인에만 속해있는 컴포넌트가 많은 경우에, 이런 컴포넌트들을 widgets에 배치시켜야할거 같은데 또 이렇게 되면 widgets 폴더가 너무 무거워질거 같고, 어떻게 풀어나가야할지 고민이 된다.

이번에 배운 내용 중을 통해 앞으로 개발에 어떻게 적용해보고 싶은지 적어주세요.

마침 회사 코드에 fsd 구조를 적용하려고 시도 중이기 때문에 응집도 높고 결합도 낮은 코드에 대해 많은 고민을 해보면서 최근 회사에서 스프린트를 진행하면서 데이터 관련 로직과 이벤트 핸들러 로직을 분리하면서 이번주에 배우고 고민했던 것들을 이런식으로 적용하는구나 싶어서 뿌듯했다.

챕터 셀프회고

클린코드와 아키테쳑 챕터 함께 하느라 고생 많으셨습니다!
지난 3주간의 여정을 돌이켜 볼 수 있도록 준비해보았습니다.
아래에 적힌 질문들은 추억(?)을 회상할 수 있도록 도와주려고 만든 질문이며, 꼭 질문에 대한 대답이 아니어도 좋으니 내가 느꼈던 인사이트들을 자유롭게 적어주세요.

클린코드: 읽기 좋고 유지보수하기 좋은 코드 만들기

• 더티코드를 접했을 때 어떤 기분이었나요? ^^; 클린코드의 중요성, 읽기 좋은 코드란 무엇인지, 유지보수하기 쉬운 코드란 무엇인지에 대한 생각을 공유해주세요

어디서부터 손을 대야할지 막막했음. 로직이나 컴포넌트를 분리하거나 기능을 추가하려고 했는데, 에러가 날까봐 건드리기도 난해했다.
읽기 좋은 코드란, UI와 비즈니스 로직 등이 잘 분리되어 있는 즉, 관심사가 잘 분리되어 있는 코드라고 생각한다.

결합도 낮추기: 디자인 패턴, 순수함수, 컴포넌트 분리, 전역상태 관리

• 거대한 단일 컴포넌트를 봤을때의 느낌! 처음엔 막막했던 상태관리, 디자인 패턴이라는 말이 어렵게만 느껴졌던 시절, 순수함수로 분리하면서 "아하!"했던 순간, 컴포넌트가 독립적이 되어가는 과정에서의 깨달음을 들려주세요

응집도 높이기: 서버상태관리, 폴더 구조

• "이 코드는 대체 어디에 둬야 하지?"라고 고민했던 시간, FSD를 적용해보면서의 느낌, 나만의 구조를 만들어가는 과정, TanStack Query로 서버 상태를 분리하면서 느낀 해방감(?)등을 공유해주세요

리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문

1. useQuery 사용과 관련해서 아래 두 가지 방식 중 어떤 방식이 더 좋을지 고민이 됩니다. 순수 UI 컴포넌트들을 제외한 나머지 컴포넌트에서는 useQuery를 사용하면 될까요?

• a. 대부분의 컴포넌트에서 useQuery를 각각 호출하고 페칭된 데이터를 사용하기.
  • 장점: 캐싱되어 있는 서버 상태 데이터를 어디서든 호출해서 사용할 수 있다.
  • 단점: 최근에 storybook을 붙이려고 보니까 전부 api를 모킹해야해서 불편했음.
• b. 페이지 컴포넌트 또는 큰 단위의 컴포넌트에서만 useQuery를 호출해서 데이터를 받아오고 하위 컴포넌트에게는 props로 넘겨준다.
  • 장점: Storybook을 적용할 때 1번 방식에 비해 간편하다.
  • 단점: tanstack query의 장점을 온전히 못 쓰는 느낌

2. 여러 개의 도메인이 존재하는 웹 서비스에서, 2-3개의 도메인에서만 쓰이는 컴포넌트들이 많아진다면 이러한 컴포넌트들은 전부 widgets 폴더에 두어야할까요? widgets폴더가 너무 비대해질까봐 고민입니다!